團隊協作絕對是重點

我翻閱了許多前輩的文章，大家都說 Azure Board 並不是一個人就玩得起來的，我完全同意這個說法。因此，在大型組織內一次靠少數人直接把整個開發流程翻掉，根本就是天方夜譚。

除了現有流程要挑戰，稽核人員、資安人員、作業人員、使用者以及開發人員都會面臨到變動，進而將新流程融入到公司未來的文化中。

一般如果有一個新的流程希望導入，我看過採取的方式大多都是：

• 由上而下的宣誓，俱備強制力的導入，強制形成文化。這種作法如果有足夠的授權，足夠的銀彈，找到對的顧問以及協力廠商，這絕對會是一個非常棒的一種方式。

但這次因為現實考量，所以我們採取的策略是：

• 由下而上的渲染。將開發人員與需求單位透過好用的協作工具進行綁定，讓他們無法離開這個平台。

第一步就是將討論作為知識保留在Azure Board 中

首先鼓勵試行的專案團隊，開始在Azure Board 上面進行所有的討論，不管是問題還是需求，所有的意見都應該盡量被作為知識來保留。

雖說我們認為短時間內，我們要成為真正的敏捷組織是極其困難的，但我們的工作預設專案，選擇了Agile-Proccess。

理由如下：

• Issue 與系統的需求是明確拆開的。
• 需求可以被明顯的歸類在功能下。

所以我們訂出了第一條建議，那就是：

• 如果你有任何問題，你不知道是該開哪種類型的工作項目，請一律開Issue。

我們怎麼看 Issue

我們把他視為對於軟體專案中，所有利害關係人或是貢獻者，意見的集合體。通常組織內進行一個專案的時候，一定會有會議，會議中大家所提出的意見，都應該被放入，在許可的範圍內越多意見越好。

那通常會議中有些人並不發言，或許是個人特質不敢在大眾面前發言，也或者是有策略性的認為會後再來各別與負責人溝通會有意想不到的結果？

這些都沒有關係，我們鼓勵將所有意見不管在會中會後，都應該完整被紀錄下來，列為待辦事項去追蹤。

還有一個重點就是，並不是所有的Issue都會直接跟軟體開發有關係，提出的意見是需要被採納後才會派工。而被移除的可能性也非常多，不論是現有功能已具備、系統限制、商業價值不符、成本過高等這些都有可能。

正規的敏捷式組織應該要有產品經理PO為這整件事情負責。但我們是傳統的金融機構資訊單位，並沒有這個角色存在，大家都知道，如果要對未確定的方向進行開發，一定會徒勞無功。但無止盡發散的需求絕對是每的專案管理以及開發人員心中的痛，而且到處都看的到這個狀況。

因此，我們打算透過這個工具將討論完整保留，讓所有利害關係人都可以專注在Issue提出，Issue的提出等於人所表達的意見，所有的軟體開發起點，都基於人的需求，再來就是釐清需求的商業價值與成本之間的衡量，最後再來決定是否進入軟體設計與開發的階段。

軟體開發專案，是絕對無法避免組織與人的問題，所以我們要面對他。